從 Codex 網頁入口進入 Cloud

Codex Cloud 是 Codex 在雲端執行開發任務的工作方式。它會在隔離的雲端環境中讀取指定的程式碼儲存庫（Repository）、修改檔案、執行指令與測試，並保留任務的執行紀錄與結果。

開發者送出任務後，可以關閉頁面或先處理其他工作，之後再回來查看執行紀錄、修改內容與測試結果。這種方式適合需要閱讀多個檔案、修改數個模組、執行完整檢查，以及整理變更說明的任務。

使用時先開啟 Codex 網頁，並以 ChatGPT 帳號登入。網頁中的 Codex 是操作任務的入口。任務送出後，若交由隔離的遠端環境執行，使用的就是 Codex Cloud。

「Codex 網頁」描述操作介面，「Codex Cloud」描述任務的執行環境，兩者屬於同一套 Codex 工作流程。

這次會使用先前做為範例的 codex-hands-on 儲存庫完成一項固定任務。Codex 需要依照 Issue 描述，為命令列工具加入 bug、feature、documentation 與 security 四種標籤的數量統計，並同步更新服務層、命令列輸出、測試與 README，最後建立拉取請求（Pull Request, PR）草稿。

連接 GitHub 儲存庫

第一次使用時，Codex 會要求連接程式碼代管服務。依畫面選擇 GitHub 並完成授權後，再指定 Codex 可以存取的帳號、組織與儲存庫。

縮小授權範圍可以降低選錯專案的風險，也方便後續管理存取權限。若專案位於 GitLab，也可以使用目前仍標示為測試版的 GitLab 連接功能。

連接完成後，在 Codex 的環境或任務選擇畫面找到 codex-hands-on。送出任務前，先確認儲存庫名稱與基準分支，例如 main。Cloud 會依照選定分支的內容建立工作環境，因此尚未推送到遠端的本機修改不會出現在這次任務中。Issue 內容也應先存在於遠端平台，或完整貼進任務描述。

如果儲存庫沒有出現在清單中，可以回到 GitHub 的應用程式授權設定，確認 Codex 已取得該儲存庫的存取權。若儲存庫隸屬組織，管理員可能需要先核准應用程式。

這些權限設定應在建立任務前確認完成，避免 Codex 讀取錯誤版本，或因權限不足而無法存取專案。

建立可重現的 Cloud 環境

選好儲存庫後，需要建立一個 Cloud 環境。環境會保存安裝相依套件、準備工具與設定變數所需的步驟。設定時應依照專案既有方式準備環境，例如從 package.json、鎖定檔與 README 判斷使用的套件管理工具，再執行對應的安裝命令，讓 Codex 以接近團隊開發環境的版本執行測試。

環境設定也可以加入測試需要的環境變數與祕密。目前標籤統計的調整不需要正式環境憑證，因此不應加入正式資料庫密碼、部署金鑰或個人存取權杖。

若測試需要額外設定，應使用測試值、模擬服務或儲存庫既有的測試資料。完成設定後，先確認安裝指令可以正常執行，再將這個環境提供給任務使用。

Cloud 在環境設定階段可以連線下載相依套件，代理人執行任務時則預設關閉網路存取。若專案需要連接外部服務，可以在環境設定中限制允許的網域與 HTTP 方法，並檢查連線紀錄。

開放網路會增加提示注入、資料外洩與下載不可信內容的風險。如不需要使用外部網路，應維持預設的關閉設定。

把 issue 改寫成可執行的任務

Cloud 會根據送出的任務描述判斷要讀取哪些檔案、修改哪些內容，以及要執行哪些驗證。若只寫「請完成標籤統計」，Codex 還需要自行推測輸出格式、修改範圍與完成條件。

先把 Issue 整理成一段可直接執行的任務，將目標、限制與驗收方式放在同一份說明中。

在 Codex 選擇 codex-hands-on 環境與 day-01 基準分支，接著貼上以下內容：

請依照這份 Issue 完成標籤統計功能。

目標：
在現有命令列輸出中，加入 bug、feature、documentation、security 四種標籤各自對應的 Issue 數量。單一 Issue 有多個標籤時，應分別計入相關項目；沒有出現的標籤顯示為 0。

修改範圍：
請先閱讀現有專案結構與測試，再修改提供統計資料的服務層、命令列輸出、相關自動化測試及 README.md 使用說明。

限制：
保留現有 Issue 排名、priorityScore 計算、輸入格式與既有輸出內容。不要新增相依套件，不要修改部署或正式環境設定，也不要建立合併提交。

驗收：
四種標籤都有固定輸出；同一 Issue 可計入多個標籤；缺少的標籤顯示為 0；既有測試與新增測試全部通過。請執行儲存庫既有的完整測試命令。

完成後請整理修改摘要、變更檔案、實際執行的測試與結果，並建立 PR 草稿。

若 Issue 描述與現有程式衝突，先說明衝突，不要自行改變既有行為。

這份描述已經把標籤種類、計數規則、零值顯示、保留行為與修改範圍寫清楚，也能直接轉成測試案例。Codex 會依照這些條件追蹤資料從服務層到命令列輸出的處理路徑，再補上測試與文件。

送出前再確認儲存庫、基準分支與 Cloud 環境，並確認任務沒有引用只存在於本機的檔案。

觀察背景執行紀錄

送出任務後，Codex 會準備隔離環境、讀取儲存庫並開始執行。任務頁面會顯示目前狀態與工作紀錄，開發者可以查看它讀取了哪些檔案、執行了哪些命令，以及測試是否通過。

較長的任務可以留在背景執行，同一時間也能建立其他獨立任務；每個任務都有自己的執行環境與變更內容。

工作紀錄可以用來確認 Codex 是否朝正確方向處理。例如這個任務應先找到標籤資料的型別、服務層處理位置、命令列輸出與既有測試，再開始修改。如果紀錄顯示它正在調整部署檔案、加入新套件或修改無關模組，就可以中止任務，修正描述後重新送出。

越早發現範圍偏移，後續需要整理的差異就越少。

如果環境安裝失敗，先查看第一個明確錯誤。常見原因包括執行階段版本不符、套件管理工具選錯、缺少測試用環境變數，或私有套件缺少存取權限。修正環境設定後再重新執行任務，並保留可以重現安裝流程的指令。略過安裝或測試會失去重要的驗證依據，也不適合作為這次任務的完成方式。

檢查摘要與跨檔案差異

任務完成後，Codex 會提供工作摘要、測試結果與檔案差異。先從檔案清單確認修改範圍，這次應包含服務層、命令列輸出、相關測試與 README.md。

如果出現套件鎖定檔、部署設定，或大量與任務無關的格式調整，就要進一步確認原因，並要求移除不必要的變更。工作摘要可以協助快速定位，最後仍要逐檔閱讀實際差異。

檢查服務層時，要確認標籤統計的資料來源與計數規則。每一筆 Issue 都應依照自己的標籤更新對應數量。同一筆 Issue 同時包含兩個目標標籤時，兩項統計都要增加。沒有任何 Issue 使用的目標標籤，也要保留數值 0。命令列層只需顯示服務層整理完成的結果，原有排名、分數與其他輸出內容也要維持正常。README.md 中的範例則要和實際輸出一致。

測試至少要涵蓋四種標籤、單一 Issue 包含多個目標標籤，以及某個目標標籤完全沒有出現的情境。接著查看 Codex 實際執行的測試命令與結果，確認完整測試已經執行並通過。若有測試失敗、遭到略過，或因環境問題無法執行，這次任務就還不能完成驗收，應要求 Codex 修正問題，或清楚記錄目前無法完成驗證的原因。

用後續指示修正結果

Cloud 任務完成後，仍可以在同一段工作中補充指示。若整體差異已經正確，只缺少一個測試案例，可以直接指出檔案與情境，例如：「請補上同一個 Issue 同時包含 bug 與 security 時，兩個計數都增加的測試。保留目前實作，不要調整其他輸出。」Codex 會沿用這次任務的上下文繼續修改，並重新執行驗證。

補充指示也要維持單一目標。若 README.md 範例與實際輸出不符，就只要求修正範例並執行相關檢查。若出現無關的格式調整，就只要求還原那些變更。

每一輪完成後，都要重新閱讀差異與測試紀錄，確認修正過程沒有帶入新的無關修改。若初始設計方向已經偏離需求，重新建立任務會比較容易取得乾淨的修改結果。

如果 Codex 的工作摘要缺少驗證依據，可以要求它補充實際執行的命令、測試數量、失敗項目與尚未驗證的限制。

這些資訊可以協助開發者判斷目前結果的可信範圍，也能整理進 PR 草稿。沒有實際執行的檢查，應明確標示為尚未驗證。

建立並審查 PR 草稿

差異與測試都符合預期後，可以依任務結果建立 PR。Codex 會把雲端環境中的修改推送到遠端分支，並產生 PR 標題與說明草稿。

PR 描述應交代 Issue 目標、四種標籤的計數規則、修改範圍，以及實際執行的測試。若仍有未確認事項，也要列在限制或待確認項目中。

PR 建立為草稿後，開發者要回到 GitHub 再次核對基準分支、提交內容、完整差異與自動化檢查。

Codex 在雲端環境中執行的測試結果可以作為第一層驗證，遠端持續整合（Continuous Integration, CI）仍要依專案規則重新執行檢查，確認不同執行環境下的結果一致。

合併前，開發者需要確認輸出格式符合需求、原有排名功能沒有受到影響，測試也能清楚表達 Issue 中的計數規則，再交由需要的團隊成員進行審查。

完成一次 Cloud 委派流程

這次練習從 Codex 網頁入口開始，依序連接 GitHub、選擇 codex-hands-on、建立可重現的 Cloud 環境，再把 Issue 整理成包含目標、修改範圍、限制與驗收條件的任務。

Codex 在隔離環境中處理跨檔案修改，開發者則透過工作紀錄、程式碼差異與測試結果掌握執行情況。

任務完成後，命令列輸出應加入四種標籤的統計結果，服務層負責一致的計數規則，測試涵蓋多標籤與零值情境，README.md 也要提供正確的使用說明。

PR 草稿則需要完整整理變更內容與驗證結果，並確認沒有混入部署設定、新相依套件或其他無關修改。

Codex Cloud 可以把環境準備、跨檔案搜尋、程式修改與測試執行放到雲端完成。開發者需要負責定義任務、控制權限、閱讀差異、確認驗證結果，以及決定是否進入合併流程。

經過這些檢查後，較長的開發任務才能形成可追蹤、可驗證、可審查的交付結果。